This invention concerns extraction of desired data from a structured data flow, especially extraction of predetermined data from a continuous flow of Call Detail Records produced by a telephone exchange.
Billing in consequence of services is implementation of the agreement between the service producer and his customer. In principle, there are two kinds of billing: decentralised and centralised billing.
In decentralised billing, the customer pays to the seller for each time of using services provided by the seller. The payment is performed either with conventional money or with some equivalent means of payment, e.g. postage stamps are used when paying for delivery of letters. A more recent example of a means of payment used in decentralised billing is electronic money where each xe2x80x9ccoinxe2x80x9d consists of a an encrypted binary sequence, which must be verified by a bank server.
In centralised billing, the use of services is monitored by the seller or by a third party. The customer is billed periodically, e.g. once a month. The bill is based on monitoring data collected for the preceding billing period. Examples of centralised billing are electricity, telephone and credit card billing. Centralised billing consists of three steps. The first step is an agreement between the parties on services and on related billing. The second step is monitoring (or measurement) of the use of services and saving of data concerning the use. The third step is formatting of the bill and sending the same to the customer. The bill is formed according to data saved in the billing system.
The centralised billing used in a telephone network is based on an agreement between subscribers and operator. The essential point of the agreement is that the subscriber gets access to telephone services, that is, he may make and receive calls, and as a compensation for the service provided he performs payments according to predetermined tariffs, as specified in bills sent to him by the operator. The bills typically include charging of two types: fixed charges and use charges. The fixed charges are independent of whether services are used or not. Use charges depend on how many calls the subscriber has made and possibly also on how many calls he has received. To be able to debit for use charges the operator must monitor made and received calls. Such monitoring is connection-based and it is performed by network switches.
FIG. 1 illustrates a known centralised billing method used in a telephone network by presenting a part of a public telephone network. For each call which is made the local exchange LE (the subscriber""s Local Exchange) performs a call detailed data collection and formats a CDR (Call Detail Record). The record contains all the information required in billing for one call as well as any desired quantity of other information related to the call. Call detailed data collection is always used when specified detailed information on a call is required for billing or for monitoring of call details. The structure of the Call Detail Record is determined by a an operation control command before the call detailed data collection is introduced. The record structure must be determined as a uniform structure in all exchange elements controlled by the network management. Hereinafter the Call Detail Records will also be called by the name of CDR and the program formatting the Call Detail Records will be called the CDR generator. Formatted CDRs are sent to the BS (Billing Centre) for post processing.
Formatting of the Call Detail Record requires that the operator establish some basis for formatting of the Call Detail Record. Formatting may be based e.g. on call detailed data collection of all the calls of the subscriber or formatting may be based on the call type, that is, whether the call in question is a normal call, a facility call, such as call transfer etc., a call free of charge, , an IN call (intelligent network call) etc. In fixed network applications there are about 30 different formatting bases. The formatted Call Detail Records are first saved in the memory and are then sent to the centralised billing system, where they are saved in mass storage, e.g. on magnetic tape or on a hard disk.
Between the exchange and the billing system there may also be an additional processing step, wherein call detailed data collection records are xe2x80x9cpre-processedxe2x80x9d for the billing system. Such pre-processing may be formatting, where e.g. a tariff class field is converted from one format into another. Whether there is pre-processing or not, call detailed data collection will produce enormous data blocks containing even millions of records, and these may be saved in the billing system""s mass storage. The records form the raw information which the billing system begins to process.
Thus, processing of call detailed data collection records takes place at a later moment as batch processing which is separate from the generation of call detailed data collection records. It should be noted that in practice billing may be even much more complicated than the example described above. E.g. in a mobile station network, each mobile services switching centre taking part in the call may generate call detailed data collection records. However, the billing principle is as described in the foregoing.
Processing of a CDR format in present fixed network telephone systems is described in the following referring to FIG. 2. The figure shows functions of the telephone exchange which are essential from the viewpoint of the invention.
The call detailed data collection process obtains information related to the call as raw data in individual messages mainly from the call control. The call detailed data collection process saves the information in a record reserved for the call. On termination of the call or in connection with interim data collection, the data collection process sends the call record as a whole in messages of various types to the process for saving of Call Detail Records. The message has a call type number indicating the nature of its contents and a message sequence number. The structure of successive messages is always the same and the type will determine which fields in the message must be filled in. If the number of fields to be filled in is less than the number of fields in the message, then void fields are filled in with a filling code. The messages are thus always sent in their entirety.
The saving process goes to read the message structure in a separate format file and starts formatting of the record from a raw data flow which it receives. The structure of the call record and of the format file is fixedly structured in the code of the process for storing the call detailed data collection. Fixed coding is done, because the place of the field in the call record is not found out from the format file. The process for saving the call detailed data collection reads the formatting file successively and from the received call record it picks up a field for locating it in the CDR, if in the formatting file the said field is defined as one to be taken along. The manner in which the individual field is coded in the CDR is also fixedly established in the code of the process for saving the call detailed data collection.
If it is desired in some application to have a different processing for some field in a message, e.g. a time field format, then this must be done through control of the application switch.
When the process for saving the call detailed data collection has completed the CDR, it locates it in the RAM block. Normally, one block can accommodate 5-10 CDRs. When the block is completed, it is saved on the hard disk of the concerned telephone exchange or it is sent outside the exchange to some I/O equipment, e.g. to the hard disk of the operation control centre. It is also possible to send received blocks directly to the post processing process.
It is possible for the operator to output e.g. CDRs formatted of some subscriber""s calls from a block saved on the hard disk of the operation control centre. This is done with a Man Machine Language (MML) command. The command starts a read program, wherein the structure of the format file of call detailed data collection and the names of fields corresponding to its sub-files are fixedly coded. Reading is performed from the ring buffer of the hard disk.
Formats saved in the formatting file will also be briefly described. The operator brings about the format he desires with an MML command. The command will first output for the operator in plain language in the monitor display all fields.l. sub-files available in the message. Thereupon the operator selects those fields which he wishes to locate in the format to be made. From the available fields the operator may take a field or remove a field, but he can not change the order of fields. When the user has made his choice, the format is completed and it may be output to the display or printed out on paper. The output will indicate in plain language which fields are present in the format.
The format may be e.g. in the form
Call Subscriber Number
whereby the name of the field is call subscriber number and the numerical value 10 expresses the place of the field combination in the CDR.
The MVIML function reads the fields (sub-files) available in the format file of the call detailed data collection process and uses the same both in the MML command, with which the user creates the format he desires, and in the MML command, with which the format chosen by the user is output onto the display or on paper. It is shown by the format file which fields can be chosen and whether the chosen field is present in the Call Detail Record CDR. The format file contains as many sub-files as the maximum number of fields in the Call Detail Record CDR.
The structure of the format file""s sub-file is of the type:
As can be seen from the shown type, it does not indicate the field name in plain language. For this reason, the names of fields in plain language as well as their correspondence in the format file are fixedly coded in the MML function. Coding is e.g. as follows:
IF CRPARA.SUB_REC(1).FIELD_IN_RECORD=TRUE THENDO:
CALL MOVB(xe2x80x9cCALL TIMExe2x80x9d,MML_FORMAT.RECORD_HEADER . . .
This means that if a field located in position 0 from a format file by the name of CRPARA, which field is here called FIELD_IN_RECORD, is true, that is, the user chose it when making the format, then it is given the name CALL TIME in plain language.
There are some drawbacks in the state-of-the-art formatting of Call Detail Records described in the foregoing.
Firstly, when Call Detail Records are sent from a telephone exchange to a billing centre performing post processing, the data flow to be sent is a big one. Above all, it contains plenty of void or unmarked fields. When the raw data flow contains data in binary form, in hexadecimal form and in ASCII form, then the formatted CDRs will also contain data which is in different forms. Data in different forms will add to the quantity of data to be transmitted from the exchange.
Secondly, if the billing centre wants CDRs of other kinds, that is, to add new fields or to remove fields presently in use, it is not only difficult but also risky to make any changes, since it must unconditionally be ensured that any changes made in the formatting file are made correctly and that the receiving end of the post processing site, that is, the billing centre, is able correctly to interpret the changed CDR data flow. In addition, some data is also usually lost when the format is changed.
Thirdly, since in the state-of-the-art arrangement the incoming data flow in all functions related to the format or field names and their correspondence in the format file are fixedly coded in the program blocks, necessary changes must always be made in the call detailed data collection saving process, in the data collection process, in the MML program and in programs related to output of CDRs when an entirely new data element is desired in the format. Besides changes in programs, the formatting file structure must also be changed and a change must be made in the conversion program of this file. The second and third items are so troublesome that the exchange supplier must know which format the buyer desires even a year before the exchange is delivered to the buyer. Thus, it is both difficult and expensive to change the format once it is made.
The present invention aims at a method not suffering from the mentioned drawbacks in use. The objective is thus a method where changing of the format is more dynamic and more reliable than in any known method. It ought to be possible to change the format xe2x80x9con the movexe2x80x9d and post processing must be prepared at once to process any changed CDRs. It should be possible to create different CDRs for various purposes and thus also to bring about CDRs which are shorter than present CDRs.
The established objectives are achieved with the method and system described in the independent claims.
The invention is based on the idea to use a special form for extracting desired data from a raw data flow. The number of forms may be high, however, so that there may be only one active form for each type of message. Each form defines exactly that information, which should be extracted from the raw data flow in order to format a CDR. When a form is activated, the formatting process will extract the data determined by the form from the data flow.
To this end, the exchange supplier formats a special mother form showing in plain language (in ASCII form) all the names and parameters of fields arriving as a raw data flow. Thus, the mother form is a file containing the message structure. Each different message has its own mother form. The mother forms are delivered to the user e.g. on a diskette. The user has a program using a graphic user interface which shows the desired mother form in the display. Beside this a user form blank can be seen and the user chooses the fields he desires simply by using the mouse to drag the field of his choice from the mother form to the user form where he drops the field he has chosen (drag and drop). In this manner the user makes his own form, which contains only the data he wants to include in the CDR. If the user so desires, he may also determine the form in which he likes the data to be. It is possible that the user wishes all data to be in binary form. The user delivers his form e.g. on a diskette to the exchange and to the billing centre.
On arrival of the user form at the telephone exchange, it can be activated at any time. When the form is active, the formatting process will use this form in the manner of a filter and extracts from the raw data flow the data corresponding to the fields indicated on the form, thus formatting the CDR. When the CDR is completed, the exchange will send it to the billing centre, which using the same form made by the user will interpret the data contained in the received CDR, that is, it creates fields and attaches the data belonging to the fields from the CDR. The names of fields are thus not transferred from the exchange to the billing centre.
Before activation of the user form, it is possible to test the form. Hereby in the exchange the formatting process makes the CDRs defined in the form and sends them to the billing centre. This for its part will find that the CDRs are test CDRs and will handle them accordingly. Only after testing has shown that the user form works correctly both in the exchange and in the billing centre, it may be put into active use.